[feat: heft-oxlint-plugin] Add oxlint plugin integration to heft#5887
[feat: heft-oxlint-plugin] Add oxlint plugin integration to heft#5887yashwanth195 wants to merge 2 commits into
Conversation
yashwanth195
changed the title
yashwanth195
changed the title
| { | ||
| "packageName": "@rushstack/heft-oxlint-plugin", | ||
| "comment": "Initial release of a Heft plugin for running oxlint, the fast Rust-based JavaScript/TypeScript linter.", | ||
| "type": "none" |
There was a problem hiding this comment.
Usually the initial release for a newly added plugin should be a minor
| const fixArgs: string[] = buildFixArgs(fix, pluginOptions); | ||
|
|
||
| // Run oxlint with JSON output so that diagnostics can be parsed and surfaced through the Heft logger. | ||
| const jsonArgs: string[] = [...commonArgs, ...fixArgs, '--format=json', ...lintPaths]; |
There was a problem hiding this comment.
In a large project, is there a risk of this exceeding the maximum CLI length?
Looks like on Linux, not a concern since typically on the order of 2MiB, but Windows only allows 8KiB, so there it could happen for a project with thousands of files.
Probably we should try to contribute to oxlint a --stdin-paths option like Git has, then hand it newline or NUL-delimited filenames via stdin.
|
|
||
| this._reportDiagnostics(jsonResult, buildFolderPath, logger); | ||
|
|
||
| // If requested, run oxlint a second time to produce a SARIF log file. oxlint can emit SARIF to |
There was a problem hiding this comment.
Does the SARIF log contain all the data we need? And if so, it seems like it would be more efficient to extract the diagnostics from the SARIF data than to pay the full lint cost a second time.
|
|
||
| private async _getOxlintBinPathAsync(buildFolderPath: string, logger: IScopedLogger): Promise<string> { | ||
| // Resolve the oxlint package relative to the project being linted, then read its "bin" entry. | ||
| const packageJsonPath: string = Import.resolveModule({ |
There was a problem hiding this comment.
We have a standard helper for resolving a package in a riggable package, since we allow the linter to be installed in the rig rather than in the individual package.
| private async _spawnOxlintAsync(invocation: IOxlintInvocation): Promise<IWaitForExitResult<string>> { | ||
| const { binPath, buildFolderPath, args, logger } = invocation; | ||
|
|
||
| // The oxlint "bin" launcher is an ESM Node script, so it must be invoked via Node directly. |
There was a problem hiding this comment.
In general, our preferred model then would be to bypass the CLI parser and directly feed the config into the oxlint binding, so that we don't have to worry about transporting all the data we need over the command line.
However, it looks like that may cause some complexity around stdout/stderr handling.
There was a problem hiding this comment.
The binding's lint() only returns a boolean and writes diagnostics straight to fd 1 (no output-file option), so capturing them in-process needs fragile stdout redirection that clashes with Heft's terminal. Keeping child-process for now.
| }); | ||
| } | ||
|
|
||
| private async _runOxlintAsync( |
There was a problem hiding this comment.
Let's start adopting ES2022+ semantics in new code (async #runOxlintAsync() i.e. ECMAScript private class members
| This is a Heft plugin to run [oxlint](https://oxc.rs/docs/guide/usage/linter), the fast Rust-based | ||
| JavaScript/TypeScript linter from the Oxc project. | ||
|
|
||
| Unlike `@rushstack/heft-lint-plugin` (ESLint/TSLint), oxlint does not perform type-aware linting and |
There was a problem hiding this comment.
Are we not passing the --type-aware CLI option?
2 participants
rushstack-heft-oxlint-plugin
Adds a new Heft task plugin that runs oxlint, the Rust-based JavaScript/TypeScript linter from the Oxc project, following the architecture of other Rush Stack linting plugins.
Features
oxlintbinary through the Heft task system.onChangedFilesHook.emitErroremitWarning--fixand other oxlint options through configuration.Incremental Linting
When
incremental: trueis enabled and a TypeScript configuration is present, the plugin listens to the TypeScript plugin's changed-files